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ABSTRACT 


The research reported in this paper was occasioned by the 
requirements on part of the Real-Time Digital Simulator (RTDS) 
project under way at NASA Lewis Research Center. The RTDS 
simulation scheme employs a network of CPUs running lock-step 
cycles in the parallel computations of jet airplane simulations. 
Their need for a high order language (HOL) that would allow 
non-experts to write simulation applications and that could be 
implemented on a possibly varying network can best be fulfilled 
by using the programming language Ada*. We describe how the 
simulation problems can be modeled in Ada, how to map a single, 
multi-processing Ada program into code for individual 
processors, regardless of network reconfiguration, and why some 
Ada language features are particularly well-suited to network 
simulations . 


* 

Ada is a trademark of the Department of Defense 
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INTRODUCTION 



\ 


The need for ever more detailed information about systems 
whose sophistication and complexity is continually growing 
inevitably places increasingly rigorous demands on the 
simulation models on which this information depends. The work 
described in this report was occasioned by the efforts of 
workers at NASA/Lewis Research Center to develop 
high-performance computer hardware to support real-time 
simulation of jet engines, both for the purpose of detailed 
analysis of system dynamics, and to support the development of 
digital controls for such propulsion systems [1]. The hardware 
is structured in the form of a network of communicating 
microprocessors running in parallel. The need for a 
higher-order language capability for programming such a network 
has led to the research described in this report. 

HARDWARE CONSIDERATIONS 

We will begin by describing the hardware being developed; a 
more detailed discussion may be found in [2], on which our 
description is based. 
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The development of complex digital electronic controls for 



aircraft propulsion systems requires engine simulations that run 
in real time and provide a high degree of accuracy and user 
interaction. In addition, the use of propulsion system 
simulations in many hardware-in- the-loop applications adds the 
further requirement that these simulations be implemented on 
dedicated, portable, and reliable hardware. The advent of 
microcomputer technology has made compact, low cost, portable 
computing power readily available. Currently available 
off-the-shelf microcomputers, however, do not of themselves 
possess the necessary computational speeds to perform accurate 
real-time simulations of complex dynamic systems such as 
aircraft propulsion systems. The approach to this problem 
adopted by NASA Lewis Research Center in its Real-Time Digital 
Simulator ( RTDS ) project is the use of microcomputers in 
parallel. By using parallel processing it is possible to retain 
the cost, size, and portability advantages of microcomputers and 
achieve the accuracy necessary for real-time simulation by 
increasing the number of computations per unit time. 

As work on this project progressed, it became clear that it 
was not necessary for the program model to reflect low-level 
details of the computer hardware on which it was to run. By 
means of progressive abstraction it was possible to create a 
high-level model that can be effectively mapped to a variety of 
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hardware configurations, ranging from the lock-step regime 
originally envisioned to the more sophisticated data-flow 
architecture that is currently being investigated. To lay the 
groundwork, we first present the hardware plan as originally 
conceived, and then indicate how it can be abstracted to obtain 
a more general model of network computation. 

The original structure of the simulator is shown in Figure 1 
(from [2]). The core of the system consists of a transfer 
schema which synchronizes up to 10 16-bit processing elements 
(PEs) on a high-speed transfer bus. All but two of the PEs 
perform simulation computations. One of the remaining PEs is of 
the same architecture but dedicated to input/output functions. 
The last PE is a special-purpose processor to link low-speed, 
operator- type functions with the high-speed simulator core. The 
Front End Processor provides an operator interface as well as 
handling of peripheral communications and other simulator 
overhead, such as downloading of programs to the simulator's 
PEs . 
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Figure 1 


The simulator operation is separated into two basic cycles - 
a compute cycle and a transfer’ cycle. During the compute cycle, 
each PE performs the numerical computations for a pre-defined 
part of the simulator task. Upon completion of these 
computations, the PE sets a transfer flag to indicate that it is 
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ready to enter the transfer cycle. The transfer schema 
initiates a transfer cycle when all PEs have set their transfer 
flags. Operator control over the simulator is accomplished via 
the Front-End Processor and the Real-Time Executive. Such 
functions as simulator programming, mode control, operator 
advisories, and commands are provided. The Front-End Processor 
handles the peripheral communications for the simulator (CRT, 
keyboard, floppy disk, etc. ). There is also a host computer 
interface which allows uplinking and downlinking of data to and 
from the host. 
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The Abstract Model 


It is immediately clear that several aspects of this 
configuration can be generalized; there is no reason that the 
model should remain specific to, say, ten 16-bit processors. 
The step to a system of arbitrary processors undergoing a 
synchronized series of compute and data transfer cycles under 
the supervision of a transfer schema is not difficult to make. 
It is less obvious, however, that the transfer schema need not 
be an actual piece of hardware, but may be virtual: the 
embodiment within the program model of the data transfer 
discipline that is in effect. Once this has been realized, it 
becomes clear that the requirement of lock-step cycles can be 
relaxed: the program model has been abstracted to a set of 

modules specifying the code for each processor, and the 
discipline for transferring data among them. A data flow 
architecture is thus among the possible instantiations of this 
model; the data transfer discipline in this case becomes 

begin computation when all required input has arrived; 
transmit data to all specified recipients when computation 
of this data is complete. 

It is important to keep this "virtuality" of the transfer schema 
in mind during the subsequent discussion. 
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PROGRAMMING LANGUAGE CONSIDERATIONS 


The use of programming languages of an abstraction level 
higher than that of assembly language is now so widespread both 
for systems and applications program development that it is 
difficult to recall how controversial such use was until recent 
years. The ability of the assembly language programmer to 
maximize program efficiency by means of direct control of 
machine operations was deemed more important than the 
convenience and programming speed gained by use of high-order 
programming languages (HOLs). 

The change in programming practice in recent years leading 
away from this state of affairs is well known. Hardware costs 
have dropped drastically, both in absolute terms and with 
respect to software development costs. Software systems have 
increased in size and complexity, emphasizing the need for code 
clarity and maintainability. Finally, the development of 
integrated microelectronic digital circuitry has led to the 
widespread use of embedded computer systems in military and 
aerospace environments that require absolute software 
reliability. 

The result of these developments has been to make the use of 
HOLs standard practice in an overwhelming number of software 
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development efforts. The urgency of the requirement for 
reliable and maintainable code has produced intensive research 
efforts in the area of programming languages and systems, with 
the result that modern HOLs not only encourage and facilitate 
the development of high-quality software while achieving 
efficiency levels competetive with hand-coded assembly language 
programs, but can be implemented expeditiously by means of the 
powerful compiler construction tools that have been developed in 
recent years. The resulting availability of ( cross- ) compilers 
has made programming even quite rudimentary microcomputers in a 
HOL common practice. 

The advent of networks of microcomputers, however, has 
resulted in a software lag once again. While compilers can be 
generated for single machines quite rapidly, each configuration 
of a network is logically equivalent to a different computer, 
requiring a new compiler to distribute code among the nodes. An 
additional problem is the dependence of the HOL itself upon the 
network. Allowing the different microcomputers to communicate 
among each other is a hardware implementation problem. How the 
HOL facilitates the generation of efficient code to provide for 
rapid communication and synchronous behavior is a software 
problem which is Just beginning to be addressed. 
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RESEARCH OBJECTIVES 


Any HOL being considered has to satisfy a host of constraints 
and requirements necessitated by the general properties of 
simulation practices and the particular microcomputer network. 
Some of these requirements are: 

1. The HOL must be implementable on any computer or 
combination of computers. In particular, it is useful to 
be able to run the simulation on a uniprocessor. 

2. The HOL must have the capability for specifying 

communicating parallel processes. 

3. The HOL must support the special requirements of 

interactive-mode simulations applications. 

An evaluation of existing HOLs led to the choice of Ada [ 3 ] 
as best suited to these requirements. A discussion of this 
evaluation and the considerations influencing this decision is 
contained in [il]. In the present report we describe 

A. A determination of suitable means of mapping the abstract 
structures of Ada into the hardware configuration. 

B. A precompiler that performs this mapping. 

C. Advantages of using Ada as the programming vehicle for 
this project. 
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PROGRAMMING MODEL REQUIREMENTS 


A consideration in the suitability of Ada for the RTDS 
project is how well the language allows the expression of a good 
programming model of the underlying physical reality. We 
imposed several constraints on the programming model itself: 

1. The program model must be executable directly on a 
uniprocessor . 

2. The program model must be as simple and natural as 

possible, since it must be readily programmed by 

non-experts and should not, therefore, involve 

complicated synchronization concepts. 

3. The program model must be safe, that is, modules 
contained within should not be able to tamper with or be 
affected by other modules' data or execution. 

U. The program model should be standardized sufficiently in 
order that it can easily be mapped to the individual 
programs suitable for the nodes of specific distributed 
networks . 

Any solution to the problem of modeling a simulator network 
in terms of Ada must fulfill the basic requirements imposed by 
the application: it must be efficient and it must be independent 

of the particular structure of the network. Our approach was to 
tailor the program to reflect the structure of the problem . not 
of the hardware . Since the hardware itself is presumably 
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designed with efficient execution of this class of problems in 
mind, efficiency is a natural consequence of this approach. Our 
solution fulfills the machine-independence requirement as well: 
the resulting program can be run equally well on a time-slicing 
uniprocessor, and, by employing the techniques to be discussed, 
on the network that is the ultimate target machine. 

As indicated, our approach is based on having program 
structure mirror problem structure as closely as possible. A 
representative case employs concurrent processes running in 
parallel to perform the requisite computations, transmit data to 
each other when done, and then resume. Our Ada model' program 


follows 

this 

structure 

exactly: 

an independent 

concurrent 

program 

unit 

corresponds 

to each 

independent pro 

cess of the 

problem, 

and 

these units 

follow the 

compute/transfer 

cycle just 


outlined . 

A central idea of our model was to collect all information 
pertaining to any one processor into a coherent, self-contained 
module, allowing a clear and elegant notation for specifying 
both computation and data transfers. As will be seen, the Ada 
package concept appears tailor-made for this purpose, and the 
Ada task concept is a natural implementation of concurrency. 
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Ada Tasks 


Processes that can execute concurrently are specified In Ada 
by tasks. The process specified by a task begins execution when 
the task's declarations are elaborated; in this sense tasks 
resemble main programs rather than subroutines. Concurrently 
active tasks can communicate with each other by means of entry 
calls . An entry of a task is specified by means of an accept 
statement, which has the (simplified) syntax 

accept <entry> ( <parameters> ) do 
<statement_sequence> 
end ; 

A task T1 can call an entry E in another task T2 by specifying 
the name of the called task and entry: 

T2 . E; 

The effect of such a call is to force process synchronization: 
if T2 has not reached the corresponding 
accept E ; 

statement, then T1 must queue up until T2 does. If, on the 
other hand, T2 reaches the 
accept E ; 

statement before another task has called entry E, T2 must wait 

f 

until an entry call to this entry occurs. Once either condition 
is satisfied, a rendesvous takes place: the code specified in 

<s tatement_sequence> is executed, with inter-task data transfer 
occurring via the entry parameters. Upon completion of the 
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rendesvous the tasks resume independent concurrent operation. 

Tasks are usually declared as a two-part entity in Ada 
programs: the task specification and the task body . The task 
specification specifies the names of the task's entries and the 
names and types of the paramenters. It constitutes at once a 
"forward declaration" and a user interface for the subsequent 
task body. 

The task body, in turn, contains the code specifying the 
process's activity. Outside entities may in general communicate 
with this code solely via entries; the task body is closed to 
them otherwise. Figure 6 gives an example of a task 
specification, while Figure 7 contains the corresponding body. 

Ada Packages 

Data/Process Encapsulation . 

The prospect of multiple processes running in parallel 
involves certain problems with respect to data access. In 
particular, obvious difficulties arise if two processes are 
allowed to update the same data simultaneously, or if one tries 
to read data that another is updating. The need to impose 
discipline on such contention led to the concept of data 
encapsulation. Data subject to contention is placed inside 
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programming language constructs that force processes to access 


the data using a set of strictly circumscribed functions. 

Packages are the encapsulation mechanism provided by Ada. 
Program resources may be collected into a coherent unit by means 
of this facility, and made available to tasks and subprograms 
that require access to these resources. It is important to note 
that the ecapsulated resources may include not only type and 
data declarations but also subprograms and tasks. 

As is the case with other Ada program units, packages are 
specified in two parts: the package specification and the 
package body . The package specification contains all the 
information that is to be accessible ("visible") to the user, in 
particular the data he may manipulate, and the specifications of 
subprograms and tasks he may reference. It should be emphasised 
that for tasks it is only the task entries that are specified in 
the task specification part, which in turn is the only part of 
the task that is present in the package specification. Figure k 
illustrates a package specification. 

A package body contains all the machinery needed to implement 
the subprograms and tasks whose specifications are to be found 
in the package specification: the subprogram and task bodies, as 
well as any variables and types required by this machinery. 
Constructs within a package body are in general invisible to the 
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user, who may access only what has been made available to him in 


the package specification. Figure 5 depicts a package body 
containing the task body for CODE; it also illustrates the 
mechanism for making a package available to a pro gram unit: the 
with statement. In this case it is the package TRANSFER_SCHEMA 
that is made available to package body FAN_INLET. 


THE ADA MODEL 

The Ada model combines the two distinct Ada constructs, tasks 
and packages, for the two programming requirements of 
concurrency and efficient data transfer. The code for each of 
the hardware processing elements is specified by an Ada task, 
which we call the hardware task pertaining to that processor. 
Using packages and visibility commands, the flow of data between 
concurrent processes can be specified and controlled by a single 
process, called the transfer schema . Consequently, if the 
transfer schema is designed and programmed correctly, then all 
communications are correct. 

As indicated above, the best way to model the processing 
elements is to use a single package for each processing element. 
The package body (normally invisible to other programming 
modules) contains the hardware task which corresponds to the 
code to be executed on the processing element. The package 
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specification (or visible part) contains all the variables 
needed for import/export and the task entries needed for 
synchronization. The major benefit of this standardization and 
data hiding is that the conversion of the model to a program 
suitable for a network is made tractable. 

MAPPING THE MODEL TO THE HARDWARE 

Many of the advantages of using a suitable HOL in distributed 
programming will be lost unless a good way is found to map the 
programming model constructed in the HOL to the individual nodes 
in the hardware network. There does not exist any compiler that 
will translate abstract programming models into code for any 
RTDS network. Such a compiler would be expensive to construct 
and would have limited utility, for any change to the network 
would necessitate major changes in the compiler. If, however, a 
single program (or compilation) is written for a network and a 
series of programs, one for each node in the network, is 
desired, then a solution is to convert the program text for the 
whole network into a series of individual program texts suitable 
for each processor. At that point a standard compiler for the 
HOL for the individual processor may be employed to derive code 
for the processor. The conversion from a single text to 
multiple texts is accomplished by a program called a 
precompiler . 
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The elegance, utility, and power of the Ada model 
synergistically coupled with especially useful Ada constructs 
argue convincingly in favor of a precompiler with Ada source and 
target texts as the best solution to the HOL-network problem. 
The expected proliferation of Ada compilers also makes the 
Ada-to-Ada precompiler solution attractive, obviating the 
construction of code generators for each kind of target 
computer. There will be more Ada compilers available for 
different processors than for any other real-time language. The 
Ada language Itself is particularly well-suited to the 
precompiler solution. One of Ada's useful features in 
bare-computer , real-time computing is the representation 
specification . The programmer is allowed to insert machine 
dependencies into Ada code; for ( example, he may specify the 
absolute address of variables or insert assembly language code. 
The ability to reach through the HOL virtual computer to the 
actual hardware is generally considered harmful because of 
potential programmer abuse. However, applications programmers 
will not be employing these representation specifications; the 
precompiler will use them to convert rendezvous code and other 
machine-dependent code into the code necessary to effect bus 
communications. Bus communication usually involves knowing 
absolute addresses and manipulating bits, both of which are 
difficult or impossible in most HOLs. However, the precompiler 
will have no trouble inserting such code, and will still produce 
an Ada program rather than an assembly language program. 
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A second feature of Ada well-suited to 


the precompiler 


solution is the pragma , or compiler directive. Programmers may 
use pragmas almost anywhere in Ada text for almost any purpose. 
Some pragmas are built in the language, for example, the pragma 
OPTIMIZE, which takes one of two parameters, TIME or SPACE. 
Other pragmas are allowed by particular implementations. If an 
implementation does not recognize a pragma, the pragma is 
ignored. We intend that the Ada program model contain pragmas 
(for example, CODE_MAP) meant for the precompiler to aid the 
precompiler in its execution. These same pragmas will have no 
effect when compiled by a uniprocessor compiler, thus allowing 
the exact same text to work on a uniprocessor directly (with 
simulated parallelism) or on a network after precompiling. 

THE OPERATION OF THE PRECOMPILER 

The precompiler was generated from a LALR(l) grammar for Ada 
by the PARGEN parser generator component of the Mystro 
Translator Writing System [5] developed at the College of 
William and Mary. It employs two passes to delineate precisely 
which variables are intended for transfer, which variables must 
be placed in absolute memory locations, which constructs 
correspond to the hardware tasks, and so on. Its final pass 
produces a series of text files corresponding to uniprocessor 
Ada programs. 
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The precompiler operates on two assumptions. The first is 
that the coding conventions dictated by the programming model 
are followed. For example, each separate processing element must 
appear in a distinct package, the first task in that package is 
the code for the element, all interprocess communication is done 
via calls to the transfer controller package, etc. These 
conventions are tailored to the problem to be solved. Changes to 
the conventions may necessitate changes to the precompiler. The 
precompiler can therefore only be used in simulations which 
conform to the programming model. This is not unduly 
restrictive, since the programming model is general enough to 
encompass a large class of simulations. 

The second major assumption is that all processing elements 
must synchronize after each computation cycle. This 
synchronicity is exploited to simplify the structure of the 
transfer controller package and the loops in the resulting 
single processor code. 

The precompiler splits a multitasking program which satisfies 
the programming model into a set of single-processor programs. 
The two conceptual steps the translator must perform are: 

Determine the names of packages that represent processing 

elements and the transfer controller. 
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For each processor package that represents a processing 
element, create a procedure to run on a separate processor. 
This procedure is formed from information obtained from the 
original processor package and the transfer controller. 

The collection of separate programs (Ada procedures) produced 
by the precompiler must be functionally equivalent to the 
original multitasking program. As has been described above, the 
original package used to represent a processing element 
communicates its values to other packages via a package called 
the transfer controller. After splitting, communication must be 
accomplished via a bus. The transfer logic resident in the 
transfer controller must thus be distributed to the split 
procedures. This is accomplished by the precompiler replacing 
waits for the transfer controller by calls to a bus package, 
followed by a wait in a busy loop. These calls explicitly pass 
or receive the values to be transferred and the destination 
address . 


PRECOMPILER EXAMPLES 

Details of how these steps are performed are given in a 
subsequent section. We first illustrate these steps for two 
sample processing element packages A and B, and a transfer 
controller package called TRANSFER_CONTROLLER . These packages 
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are identified to the precompiler via the pragma compiler 


directive. We then show the effect of the precompiler on the fan 
inlet example of Figures U , 5, 6, and 7- 


Here is the 
correctly on 
precompiler to 


original Ada program. This program will 
a uniprocessor, or can be processed by 
produce the split procedures shown below. 


run 

the 


pragma code_map ( internal => A, actual => "CPU_A"); 
pragma code_map ( internal => B, actual => "CPU_B"); 

— the above pragmas tell the precompiler which package 
-- ("hardware task") will be mapped to which actual machine 

pragma transfer ( TRANSFER_CONTROLLER ) ; 

-- This pragma tells the transfer controller that the data 
-- transfers are specified in the package named TRANSFER_CONTROLLER 

package A is 

x, y: integer := 1; -- moved to split procedure 

task A_code is 

entry START_UP; -- replaced by precompiler 
entry RESUME; -- replaced by precompiler 

end A_CODE; 
end A; 

package body A is 

task body A_CODE is 
begin 

accept START_UP; -- replaced by precompiler 
loop 

x := x + y; -- or any arbitrary computation 
TRANSFER_CONTROLLER . SIGNAL; -- signal completion 
accept RESUME; -- replaced by precompiler 
end loop; 
end A_CODE; 
end A ; 


Figure 2 . a 
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package B is 

x, y: integer := 1; -- moved to split procedure 

task B_code is 

entry START_UP; -- replaced by precompiler 
entry RESUME; -- replaced by precompiler 
end B_CODE; 
end B ; 

package body B is 

task body B_CODE is 
begin 

accept START_UP; — replaced by precompiler 
loop 

x := x + y; — or any arbitrary computation 
TRANSFER_CONTROLLER. SIGNAL; -- signal completion 
accept RESUME; -- replaced by precompiler 
end loop; 
end B_CODE; 
end B ; 


Figure 2 . b 
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task TRANSFER_CONTROLLER is 
entry SIGNAL; 
end TRANSFER_CONTROLLER; 

task body TRANSFER_CONTROLLER is 
No_of_processors ; constant = 2; 

Signal_count; integer range 0 .. No_of_processors; 
begin 

-- start up both processes: 

A. START UP; 

B. START_UP. 

loop 

Signal_count := No_of_processors ; 
while Signal_count > 0 loop 
accept SIGNAL; 

Signal_count := Signal_count - 1; 
end loop; — busy wait for everybody to finish 

A. y := B.x; — moved to split procedure 

B. y := A.x; — moved to split procedure 

A CODE . RESUME; 

B CODE . RESUME; 

end loop; 

end TRANSFER_CONTROLLER; 


Figure 2 . c 


The packages shown in Figures 2. a, b, and c will run 
perfectly well on a uniprocessor, simulating concurrency and 
allowing the programs in question to be debugged. When 
desired, they can be mapped by the precompiler to Ada code 
that will run on separate machines, communicating via a 
hardware bus. The precompiler produces as output the 
following Ada programs: 
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with BUS; use BUS; 
procedure A is 

x, y: integer := 1; -- moved from original package 

begin 

-- the following loop is created and inserted by 

-- the precompiler 

loop 

exit when INPUT_READY ; 

— busy loop, waiting for signal 

— corresponds to accept START_UP in original 
end loop; 

loop 

MOVE ( TO => y, FROM => x_LOC ) ; 

-- MOVE is a bus package procedure. This call is 
-- created and inserted by the precompiler 

x : = x + y ; 

-- TRANSFER is a bus package procedure. This call is 
-- created and inserted by the precompiler 
TRANSFER( VALUE => X, SEND_TO => B, ADDRESS => y_LOC ) ; 

-- the following loop is created and inserted by 

-- the precompiler 

loop 

exit when INPUT_READY; 

-- busy loop, waiting for signal 
-- corresponds to accept RESUME in original 
end loop; 
end loop; 
end A ; 

Figure 3 • a 
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The procedure for B is similar: 

procedure B is 

x , y : integer : = 1 : 


begin 

loop 

exit when INPUT READY : 

— busy loop, waiting for signal 

— corresponds to accept STAP,T_UP in original 
end loop; 

loop 

MOVE (TO => y, FROM => x_LOC); 

x : = x + y ; 

loop 

exit when INPUT_READY; 

— busy loop, waiting for signal 

— corresponds to ac cept RESUME in original 
end loop; 

TRANSFER( VALUE => x, SEND_TO => A, ADDRESS => y_LOC ) 
end loop; 

end B ; 


Fit ire 3 . b 
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A JET ENGINE SIMULATION EXAMPLE 


We now give a more realistic example, representing a portion 
of an actual jet engine simulation. Suppose that the code for 
the FAN_INLET computations of a Jet engine simulation is to be 
assigned to hardware processor 1. This assignment is specified 
by means of the pragma shown in Figure U . The code depicted 
there corresponds to the visible part of the FAN_INLET routine. 
The entries START_UP and RESUME are needed for synchronization. 
When either is called (like a subroutine), the execution of the 
code for FAN_INLET can start or resume. Each of these package 
specifications can and should be compiled separately. 
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pragma CODE_MAP( INTERNAL => FAN_INLET, 

ACTUAL => "processor 1"); 
— Informs the precompiler that 

— code for FAN_INLET will be 
-- on CPU node processor 1 

pragma transfer ( TRANS FER_SCHEMA ) ; 

package FAN_INLET is 

— Here are the declarations of 
-- the transfer variables. 

-- They will need addresses for 

— bus transfer and the data base: 

A, B. C : VECTOR; 

-- Here is the task specification 

— with synchronization entries: 

task CODE is 

entry START_UP; 
entry RESUME; 
end CODE; 

end FAN INLET ; 


Figure H 


The Ada compilation unit which contains the code for 
FAN_INLET is given in Figure 5- The with statement is a 
directive to the compiler that this package body should be 
compiled with the specification of the transfer schema task. 
This is necessary since entry SIGNAL of the transfer schema is 
called. The body of the package consists of the task body only. 
The task body contains three rendezvous which are the Ada 
constructs used for communications between tasks. 
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with TRANS FER_SCHEMA; 

package body FAN I N LET is 

-- Here is the body of the task: 

task body CODE is 

-- Here are local declarations 
-- not involved with data transfer. 
-- These will need addresses: 

TEMP : VECTOR; 

begin 

accept START_UP; 
loop 

TEMP : = A; 

A : = A + B; 

B := TEMP - C; 

TRANSFER_SCHEMA. SIGNAL; 
accept RESUME: 
end loop; 
end CODE; 
end FAN INLET ; 

% 

Figure 5 


The text for CODE has these semantics: Task CODE is suspended 
until it receives a call (from the transfer schema) to the entry 
START_UP. i The task then enters an infinite loop which consists 
of its calculations, a call to an entry of the transfer schema 
Indicating that its calculations are done and its export 
variables are ready for export, and suspension until it receives 
a call (from the transfer schema) to the entry RESUME indicating 
that the variables necessary for the next cycle have been 
imported . 


As can be seen from the models for the hardware processing 
elements, a critical cog in the overall model is the transfer 
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schema task. Its specification, given in Figure 6, must be 
compiled with the task bodies described in Figure 5 . The body 
of TRANSFER_SCHEMA , given in Figure 7 . must be compiled with the 
package specifications corresponding to the processing elements 
since the transfer schema task must be aware of the 

import/export variables and the synchronization entries. 

task TRANSFER SCHEMA is 

entry SIGNAL; 
end TRANSFER_SCHEMA; 

Figure 6 

The. body of, the transfer schema contains two local 

declarations: a constant TOTAL indicating the total number of 
processing elements to be synchronized and a counter variable 
COUNT to tell when all the processing elements have completed 
their calculations. 
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with FAN_INLET ; 
with REAR_DUCT: 
with FORWARD_SENSOR; 

task body TRANSFER_SCHEMA is 

No_of_processors : constant := 3; 

Signal_count : INTEGER range 0 . . No_of_processors : 

begin 

-- start up all three processes: 

FAN_INLET. CODE . START_UP; 

REAR_DUCT. CODE. START_UP; 

FORWARD_SENSOR. CODE. START_UP; 

loop 

Signal_count := No_of_processors ; 
while Signal_count > 0 loop 
accept SIGNAL; 

Signal_count := Signal_count - 1; 
end loop; -- busy wait for everybody to finish 

FORWARD_SENSOR. W := FAN INLET. A; 

REAR_DUCT.X ' := FAN_INLET. C; 

FAN_INLET. CODE. RESUME; 

REAR_DUCT. CODE. RESUME; 

FORWARD SENSOR . CODE . RESUME ; 

end loop; 

end TRANSFER_SCHEMA; 


Figure 7 


The code for the transfer schema has these semantics: all the 
hardware tasks are started by calls to the START_UP entry in 
each hardware task. Then the transfer schema enters an infinite 
loop in which it awaits entry calls from the hardware tasks 
indicating that they have finished their computations. The 
"accept SIGNAL" in the transfer schema is matched with the 
"TRANSFER_SCHEMA. SIGNAL" entry calls in the tasks for 
rendezvous . 
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After all the tasks have signaled completion, the transfer 
schema transfers the variables. 

FORWARD_SENSOR. W := FAN_INLET . A 

means that the value of variable A in FAN_INLET is to be stored 
in the location of the variable W in FORWARD_SENSOR . In a 
uniprocessor, this is a straightforward assignment. In a 
network, the assignment will be converted to instructions (calls 
to a bus handler package) to allow the value of A to be 
communicated by the bus to the location of W. After the 
variables have been transferred, the transfer schema signals 
each hardware task to resume execution by calling the RESUME 
entry of the task. Recall that the tasks have been suspended 
while the variables were transfered because of the "accept 
RESUME" statements. This completes the cycle of execution in 
the transfer schema. 

The Ada program model for a processing element in Figures H 
and 5 will be converted by the precompiler to the main program 
given in Figure 8. The two busy loops are broken either by 
interrupts or a switched bit (depending on the nature of the bus 
communications) to synchronize the startup and the import of 
data. The system library function INPUT_READY may be coded 
independently of the precompiler to accomodate changes in the 
network configuration or basic design. The system library 
procedures MOVE and TRANSFER control the moving of data from the 
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bus depot to their memory locations and the moving of data from 
memory to the bus depot and then through the bus itself. The 
code for these system library routines may be high-level Ada 
code, assembly language, a call to a hardware procedure, or a 
combination of these that moves the export variables to the bus 
depot and signals that the import variables have all arrived. 
The three routines are located in the package BUS, and may be 
named directly because of the "with" and "use" clauses 
preceeding the main program FAN_INLET. The rest of the code 
mimics that of the original hardware task. 
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with BUS; use BUS; 
procedure FAN_INLET is 
A. B, C : VECTOR; 

for A use at 16#A0#; 

for B use at l6#A8#; 

for C use at 16#B0#; 

for TEMP use at l6#B8#; 

-- 16 tt indicates that the 
— addresses are hexadecimal 


begin 

— the following loop is created and inserted by 

— the precompiler 
loop 

exit when INPUT_READY; 

-- Busy loop, waiting for signal 
-- that input arrived at depot. 

— Corresponds to START_UP. 
end loop; 

loop 


-- Move variables from bus depot 


-- to their memory 
MOVE (TO => A. FROM 
MOVE (TO => B, FROM 
MOVE (TO => C, FROM 


locations . 
=> A_LOC ) ; 
= > B_LOC ) ; 
=> C_LOC ) ; 


TEMP := A; 

A : = A + B ; 

B : = TEMP - C; 


— The value of A will be sent 
-- to FORWARD_SENSOR to be 
-- stored in the bus depot 


— for variable W there. 


TRANSFER( VALUE 

SEND_TO 

ADDRESS 

TRANSFER( VALUE 

SEND_TO 

ADDRESS 


= > A, 

=> FORWARD_SENSOR, 
=> W_LOC); 

= > B, 

=> REAR_DUCT, 

=> X_LOC ) ; 
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— the following loop is created and inserted by 

— the precompiler 
loop 

exit when INPUT_READY; 

— Corresponds to RESUME in original 
end loop; 
end loop; 
end FAN_INLET; 


Figure 8 

PRECOMPILER CONSTRUCTION TOOLS 

The MYSTRO translator writing system [5] was used to 
implement the precompiler. Many of the problems encountered in 
constructing compilers or, in this case, a precompiler, admit 
the same solutions regardless of the specific language being 
translated. MYSTRO employs several skeleton compilers 
appropriate to most programming languages. Except for minor, 
clearly-marked areas, any skeleton's code can be used to produce 
a complete listing, read lines for parsing. produce symbolic 
cross-references, and so on. The particular skeleton chosen for 
this project also includes hashing routines and multi-level 
error recovery. 

The initial precompiler was generated by the MYSTRO parser 
generator PARGEN, which computed and merged parse tables for a 
complete Ada grammar into the skeleton compiler. Pascal 
semantics were included in the input grammar, and automatically 
inserted into the SYNTHESIZE procedure, which associates 
semantics with the appropriate syntax. 
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OPERATION OF THE PRECOMPILER 


In order to split the original multiprocessing input program 
into separate uniprocessing programs that will run on the nodes 
of the network, the precompiler makes two passes: an 
information-gathering first pass, and an output second pass. 
While gathering information, the precompiler must know which 
packages represent processing elements and mark sections of 
their code. It does this by creating, as part of its semantics 
for the CODE_MAP pragma, a list of the packages that represent 
processing elements. Each element of this list holds information 
needed to split the program into the intended separate programs. 

Once a processing element package specification is found, the 
location of the start of the specification is noted in that 
package’s descriptor. The first task specification encountered 
after processing the package specification designator is marked 
in the descriptor and designates the end of information needed 
from the package specification. At this point the precompiler 
also records in the descriptor the names of all the entries 
declared within the nested task specification. 

When the body of a processing element package is found, the 
package descriptor is stacked to allow for package nesting, thus 
preventing erroneous location information. The task body's 
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location inside the package body is recorded in that package’s 


descriptor. This task body corresponds to the nested task 

✓ 

specification found in the package specification. Inside this 
task body, the loop and end loop for the outermost loop are both 
recorded in the descriptor to allow for the transfer of bus 
variables in and out of the simulated processor. Throughout the 
task body, entry names found in accept statements are compared 
with the entry list within 'the package's descriptor. The 
locations of those that match are recorded and the rest ignored. 
These accept statements will be converted to busy loops in the 
rewriting phase of the precompiler. The end of the package body 
is also recorded as the end of the information needed to 
complete this processing element package. 

Information regarding the bus variables and the synchronizing 
entries must also be gathered during this first pass; they are 
found inside the specification and body of the transfer 

controller. Several lists are created during the first pass: 
entries declared within the transfer controller's specification, 
variables to be moved into each processor at each loop iteration 
within the processor, and variables to be transferred to the bus 
depot for use in another processor at the end of each loop 
iteration . 

The information-gathering first pass is by far the more 
complex of the two passes. It is a straightforward matter to 
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separate the file containing the input program into several 


files containing processing element programs. 

The complexity of the first pass is mitigated by the fact 
that the precompiler is syntax-directed. The Ada grammar 
consists of nearly five hundred rules, only a small portion of 
which affect the precompiler's task. Each rule is like a small 
program; the programmer need only concern himself with 
developing correct semantics for that rule and passing 
information through the semantics stack to other rules. For 
example, the rule 

<pragma> : : = pragma Cidentif ier> 
can be used to associate with CODE_MAP semantics that enquire 
about the identifier. In fact, the SYNTHESIZE procedure contains 
the following case: 

(* <pragma> pragma <identifier> *) 

if <identif ier>. id = 'CODE_M‘\P ' then 

<pragma>. flag : = true 
else 

<pragma>. flag : = false; 

MYSTRO contains utilities to translate notation such as 
cidentif ier>. id into the appropriate stack references. 
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ADVANTAGES OF ADA 


In addition to representation specifications and pragmas, Ada 
has a variety of programming features especially suited to 
interactive-mode simulation applications. Some of these are 
described below. 

Safety in the Multi - Programming Mode. Ada encourages two of 
the main software engineering techniques to facilitate the rapid 
construction of reliable software for large and complex software 
projects. These two techniques, data encapsulation and safe 
separate compilation, are employed in the packages that mimic 
network nodes. The package body (normally invisible to other 
programming modules) contains the hardware task which 
corresponds to the code t be executed on the processing 
element. The package spec ification (or visible part) contains 
all the variables needed fo. import/export and the task entries 
needed for synchronizatioi . Finally, use of Ada separate 
compilation facilities guarantees that processing elements 
cannot communicate directly with each other, that is, a 
programmer cannot make use of the "innards" of one processing 
element when describing the behavior of another. This frees the 
programmer of the responsibility of effecting the bus 
communications directly and also allows the Ada programs to run 
on uniprocessors without any change in code. Such orthogonality 
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allows programmers and engineers to concentrate on individual 


processing element correctness and efficiency without worrying 
about ripple effects on the other processing elements. 

Abstract Data Types . Ada's abstract data type capability 
diminishes the distance between the programming model and the 
original simulation applications. Through the generic and 
package constructs, new data types specific to the application 
can be created together with the operations necessary to 
manipulate these types. These operations are allowed to have 
standard forms such as + , <, and so on. For example, in a 
package specification we may create a type VECTOR together with 
plus operations (all denoted by +) for various combinations or 
scalar and vector addition. It is expected that many packages 
particularly suited to real-time simulation applications will be 
constructed and sold by cotimercial vendors (perhaps in Ada 
Package Stores). Consequently program systems may be partially 
built with off-the-shelf components instead of being 
hand-crafted each time. 

Real-Time Constructs . Ada has a variety of real-time 
features which allow real-time constraints to be employed in 
simulation applications. These include the ability to 
deactivate a task for a specified period of time, as well as 
wait a specified time before aborting a prospective rendezvous. 
Moreover, a predeclared package CALENDAR allows arithmetic on 
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wall - 

clock times and durations, as 

well as access to 

the system 

clock 

One 

specific 

application 

is to monitor 

lock-step 

compu 

te-data 

cycles . 





CONCLUSION 


The concept of implementing a higher-order language on a 
computer network by means of a precompiler has proven to be 
extremely fruitful. Not only was it possible to map programs 
for the original lock-step network design onto the hardware, but 
it now appears feasible to apply this technique to more general 
network designs. Moreover, many of the system facilities 
required for interactive-mode simulation can be implemented by 
means of precompilation. Our research has demonstrated the 
usefulness of this approach both on the original hardware design 
and on networks of more general structure. 
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appendix 


EXAMPLE PRECOMPILER RUNS 



ORIGINAL PROGRAM INPUT TO PRECOMPILER 


The following program is the result of translating a sample 
FORTRAN simulation program furnished by NASA/Lewis into Ada. As 
can be seen, the format of this Ada program conforms to the Ada 
model described in the report. It consists of tasks A, B, C, D, 
and IOP, and a TRANSFER_CONTROLLER to move data among them. This 
program will run on any machine with a full Ada compiler. It was 
processed by the precompiler, which split it into separate 


procedures intended to run on the nodes of a network. 
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£62 




os gin — n u r> y mein orocen-jr ? 

j 

£ 6 4 

n u 1 i : 


2 6 5 

end; 
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OUTPUT OF THE PRECOMPILER 


The following Ada procedures A, B, C, D, and IOP were 
produced as output by the precompiler processing the previous 
program. The intent is that " each of these procedures be 
assigned to a processor of the network, as specified by the 
pragmas of the original program. Note that the the precompiler 

has replaced the data transfers specified in TRANSFER CONTROLLER 

by calls to the MOVE and TRANSFER entries of the bus package. 


A. 9 


ORIGINAL SS- 

f pro : “ciurs - is OF POOR QUALTTY 


c 

procsduri 1 is 

x-:FZ, x 3 _\*: : viC' r? : 


f 

X 3 I\XZ| X?C’.X2 : Mr.ZTC- 

: = 

c - : ; 


b a j i n 



f 

loop 




exit 'Vhc-n I N c IJ T _ R 

- A 

:y : 


— 5usy loop* iroit 

i n 

- for slop.-! 

f 

--corresponds to 

r • 

^ *r i t 3 


end loop; 




loop 



c 

dCVrCTc => -XPCN, 

F 0 

0,v -> X ? r?;_L 


MOV EC TO -> XNP2» 

■** “V 

Of.: => 


X ? X 2 := vr .?2 + 

A . 


r 

X ? 0 N X 2 := Co A I Vi 7 

: v 

- c x ? • j x " ) : 


7RAMS"-:CViLiJ7 

= s 

X . 


; " :;2 tq 

= 0 

: ■: p , 

c 

AO ORE 35 

= > 

x»r.'x:_Loc ) 


TRAMSFoRC VALUE 

= > 

X 5 0 X 2 , 


S“M0_T? 

= > 

L ♦ 

i 

A 33 "S3 

= > 

X c 0'!_'_: C 3: 


TRANS?; R< VALUE . 

= > 

x 3 o •; x : , 


sfnc.tc 

= > 

L- « 


A OCR CSS 

= > 

X OC 3: 


TR4NSFS?CV4LO£ 

= > 

X 3 0 N X 2 , 


S r _T C 

= > 

A * 

€ 

A ~ : ?. F 5 S 

= > 

X F 3 N_ L C C 3: 


loop 

exit Bhsn INPUT^Sf ADY : 

$• — 5usy loop* israitins for* si sn?l 

--ccrr asoont'ia to c . FSl ,? -‘2 
snc loop ; 

© end loop; 

end A l 

t 


t 
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0RIG3MAL PAGE IS 

OF POOR QUALITY 



procedure 2 

is 


j 

procedure 3 

1 s 



X :j ? 2 . X 3 

: \ , x = j-.° 

< 

.11 

O 

- « 

t’\ i 

J 

! *) 

i 

x?r;x, x? 

}NX 

: v - c T : ' 


begin 



1 

loop 




iv> 

i 

i > 

j 

! ) 


j 

> 

> 


a x i t id ", s n I !' P U T _ R ? A D Y : 

--Susy 1333, tr r, i t i r- ; for si:n?l 
-- cor r 3 spends to STIKT^IJ- 
end loop: 
loop 


MCVSCTC 

-> x?CN, 

r R1 

M => X 

oc >: 

MCV1CT3 

= > x ? ? N ^ 

, -7 

Ij V. -r > Y 5 2 f p 

_L OC 5 

m : v : c t: 

= > X fc 3 2 , 

W \ ‘j 

M -> x*:i»2j. 

p r ) • 

x 35 :: x : 

= X'; c 2 «• 

1*5 

H-;. ;/r v; * y 

0 0 M ? ) ; 

X 3 0 ■; x : 

= D 271 ViT 

■nr / 

A • - \ 

x -• ; V ) : 


: .? a 5 .= 2 

7 C v ; L Li 7 

= > 

'X 



c ~ * i n r n 

•=> 

♦ 



ir R 7: $ S 

= > 

x = ’:x_l_7 ): 


7 7 i ?,• S ' *: 

- C v : u ■ 

- > 

x 5 : *j x . 



- - A - G J 

T A A n $ = = R C V - L u 

3 3 *< _ _ 73 

- 3 3 * 3 3 > 

loop 

ax*, w i • v? n _ - . . j i - . . 

— Susy loop, rr.itirr: re 
--c c r r ~ s :>e r. ds to ~3 3U”“ 
end 1 o o rj : 

•end loop! 


— n : 

— s ■„ « 

r > X ? 'i 7 L 1 c ' ; 
-> x 
= > . 

= > X 3 ON r L:C ): 




ena S ; 
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CEi'GSMAL page J 3 

POOR QLfAUTY 


procedure C ii 


procedure C is 

x.‘i ? 2 , x ?:?.•, x^D?. 0 : v - c ~ ^ : 

x:,\, x : v'CTC? := c?I “I?.*: 

begin 

loop 

exit tL-n a n IMFIJT.5 r iOY; 

— 3 u s y loco* waiting Tor 5 i 0 r. ? 1 
--:orr 3 spends "to Slid T_U p 

end loop! 
loop 

MCVcCTO => XPC-f J, r " Q M => X»3MJ.GC )t 
MCVcC TO => X?CN°, e RC« -> X?CM»_LPC )! 
:j .CV;(T " => X ? 3 • r ~2M'-> X^oJ.T’C )t 

x := x r: p 3 - 1 . ;* h*c x = 
x : n : = j 1 " 1 v i 7 : v : c x ro : 

T R a ?J s F = P C VALUE => X2N. 

S-KC.T3 => 0, 

A 2 D k ? 5 S => X2N°2_L0C ) t 

t " i ;; s f ' ?< v :'t u ? => xm» 

SrNC.TC => 5, 

ACZ-AZSS => X N ® Z _ L 0 C It 

Tsi:;s c : "< v;lu 3 => xn, 

Sif.'D.T.? = > A,' 

A 0C -. *- SS => X\?2_LCC 1: 

1 o 0 p 

exit 'ihfft I ‘I ? U 7 _ ~ £ i 2 Y : 

— 1 l 3 y loop. I'ait’.n : for suns! 

--ccrr jspon;is to 5 3 S U *4 E 

end loop; 
end loop; 

end l; 


- 3 .?*X»DNP); 
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ORIG^&L Fg&S' & 

OF POOR QUALITY 


procedure. D is 


proceoure ■_ is 

A | X;. *2 * , “ w : r • 

X N ? V 5 - T 1 


£ T - » > I ■ 
' Ijl : t 


a^gin 

loop 

exit a'hc-n I *-i ? >J T _ R 5 1 -5 Y : 

- - :• u s y loop, wsitin? +or signal 
--corresponds to 3TAP T _'J? 
end loop; 
loop 

MOV' (Tj => XDNP2, r?C y => X0N p :_LC'C 
C V :CT j => X f: ? 3 ♦ c tQK => X\'°3 J- CC ): 
X ?! ? : = X \ - i + z. 0 * H XOAi^’T 

:< 3 : = : = * l v i t i v " c x f. = ) : 

T p : 3 *< v CLUl => X N c , 

S=MC_TC => D, 

A D j R " 3 3 => X'j? 3_LCC ): 

T S A •* i 3 = o C V A L 'J " => XV*, 

> ■: N * _ T " - > C » 
a jZP.zsz => lcc ■): 


5 x 1 1 ir-:-n I • ; ? U 7 _ ” A '• Y ? 

— — Susy loco, for sicr.-rl 

--corresponds to P. rS U ” S 


e r, :: too P 
e r, o loop 
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> 

oroceoure I J 0 is 


> 

procacuri IGP is 



XrfiX , 


> 

< = f. X Z : v 3 C T 2 : 



us a T5XT.I0; 


» 

pack a 39 I N T _ I G is neu! I N T : r. 3 

~ _ I Z C ! ?! T = S 3 R ) : 


package R E £ L_ 1 2 is na^ji FLOAT 

u s a :;-r - e a l _ : r ; 

_I.rC c LC-T) : 

1 

5 1 « I \ ! T " ; a ! - 1 I 

: FLO -IT := o.ob: 


) 

TV array ( 1 . . 5 0 0 ) of ~ L C A 

♦ • 
• • 


XV : array (1..S00) of s L\i 

• » 
• • 

> 

is a g 1 r, 



atCsct 2 3 3 'J 3 t 

TV(1) : = TIN.*; 


) 

transfer controller .signal: 

■For I in 1 . loo p 



MCVSCTG => X N X 2 , •='-••' => 

x = ::X 2 _loc ); 

) 

MOV r (TO => X-NX. -> 

xrnx_l ?c >: 


loop 



exit -jjhsn IN f 'jT _ = 3 A 3 Y : 


) 

--Susy loco , maltin': ■'or 
--corresponds to PEGU”: 

s i gr. al 


e n c: loop; 


) 

xvcs: ) c :tstcx-?, o 

« 

• 


xvcsi ♦ i) : = F 2 “ 5 T ( X 5 N X 2 
1 * NT > 1 than 

) : 

) 

tvcsi; := t v csi - n ♦ 

-J • 
• • 


and if I 

T V C 5 1 * 1 ) : = TVCSI) T H : 


i 

51 : - Si * 2 : 



and loop: 
? U T C t: ) ; 


J 

5 u t _ l I r: T : 

for 1 in 1 . . + 1 loo :• 



?■ u t ( t v ( : ) ) : 


J 

? u T ( x v ( : ) > : 



croze curs 1 0 P i • 


end loop! 


a nc. ; 


I 
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RUN OF THE PRECOMPILER OUTPUT ON A SIMULATED NETWORK 


The procedures output by the precompiler were run on a 
network simulated by a set of Ada tasks running on a WICAT 
computer on which a large subset of Ada is implemented. Each 
task of the following program represents a processor node of a 
network. 

After the original program was split by the preprocessor, the 
components were moved to the WICAT and all non-supported Ada 
features were removed (manually). The components were then 
recombined into the following program, compiled using the WICAT 
Ada compiler, and run. 
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ORIGINAL PAGE IS 

OE~POOR QUALITY ~ 

This las arogran consists of ssvsrs 1 compilation units and compiles 

0 

O This Ada program consists of ssvara 1 compilation units and compiles 

' _ on the ..'Wi.c.a.t .Ada .. .compile r. .._ 

It ras produced by running the precompiler written by Laurie King 
-- on the file Another. a c!a which contains the source (almost) equivalent to 
tne Ada pr og.r am. .or i gin al ly run at ICASr . . . 

O -- After splitting the program the components were moved to the Wicat and all 
non.-suppo.r ta.d_Ada_f ea tur es were r emov ad ...... .The„ component s were _then 

recombined and compiled. Two ciiscrepei cies from the IC A SE-cor rec t version 
.J -- were discovered and corrected! Variables mere mistyped resulting in 
other. program variable names. ... .... 

„) with global! use global; 

u/ith vectors;. ..use. .vectors • . ... ... . 

with bus ; use bus ; 

J WITH TEXT_i:; use T:X T _IC; 

. --WITH I N T r G E R _ X 3. • 

- - F L C A 7 _ 1 0 ( F l C A T ) ; 

,J Use intager_ic,float_io; 

._ Rro.cQdure_.jiiain..is . ... 

task A is end; 

J task 3 is end; 

task C is. end. ... . .. .... . 

task D is end; 

») task IQP is end; 


task body A is 

J X N P2, X ? ON : VECTOR; 

. XPUXZt XP0MX2 : VECT 0 R : 

« ) begin 

loop 

.j exit when I N R U 7 _ R ? A D Y t 

--Eusy.loopi waiting for. signal 
--corresponds to ST ART_ijp 
«) and loop: 

loop 

• M 2 V E ( X P C :W , X P 3 '■! _ L 3 C ) J 
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9 


* 

9) 

*> 


e 

e 

% 

♦ 

9 

J 




This Ada progrsn consists of sevtrr.l compilation units and compiles 


put_line("A") 
•MOVE ( XN?2 t XNPZ. LCC ) J --- .. 

XPUX2 *.= XN P 2 + •* . 0~H"X?D 

X ? D ?i X 2 := 0 3 R I V A T 2 V 2 ( X F ?! X 2 
T.R A *•; S.r 2 2(J(-P.ilX.2.» . 

!0P_task, 
XPNX2.L3C ): 

. TRANSr 2RCX?SivX2»- - 
C _ t a s l < , 

.X 3 Df. ! _L0C ): 

T R A !i 3 £ =?.<.X ?JJ.« X2 

3 _ t a s k i 
XPDN.LOC )5 

. . T R A N S r E R ( X. P.0 !-; X 2 » - - 

A _ t a s k » 

X ? 0 ?! _ L 3 C )? 

exit urban INPUT. R = A 3Y J 


3 u s y loopi waiting for 

—corresponds— to .PESU M 5 

end loop; 
end loop; 

e n d A ; 

task body 3 is 

X N P.2 , X ? 0 !:i > ...X ? 3 ...V 2 C.T 3 2 ? 

X ? i\ X i X 3 0 : ? X : V H C T c ~ : = 


b eg i 


n 

OOP 

e 


n ■:! 

OOP 

M 

P 

M 

K 


xit when I N’P 'JT_ R S.i 3 Y .* 

-Susy .loop.) .waiting for sicnal 
-corresponds to S7AR T _ : J? 
loop; 

GV2CXP0N, XPON.LGC ): 
ut_lineC"3"> : 

.aV2CX?_CNP.,.. X°3.‘J?_L3C ) ; 

0 V 2 ( X N ? 2 » X K ? 2 _ L 0 C- ) 5 


;<??! y ; s XNP2 + 1 . 5*H*(X»0N + X ®OWP) ; 
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ORIGINAL PAGE* 13 - 

OF POOR QUALITY 

W < 

I 

! -- Tn is Ada program consists o f several compilation units and compiles 


* 

* 

I 


XPONX := 0SRIVATIV5CXPMX) : 

.... -IRAN SE= P.XXPJ; X., 

I0P_ta.sk. 

X 0 N X _ L o c ): 

. J. RA fis E c R C.Xj? C.K X, ... 

C_tas!<, 

X °0N ?_L Q C >; , 

7 .R.A.NS F.E 5 C.XP.D.NX. . - - _.. 

3 _ t a s !< , 

X P 0 N 3 _L 0 C ): 

1 o.o p 

exit u/hen INPU7_R3ADYJ 

--3usy loop . • waiting tor signal 

. ^corresponds -to ..RESUME ._ — 

end loop ; 
end loop; 

en.a_3J 


> 

. task., body.. C._. is _ 

XNP3» XPDN, X P D N ? : VECTOR 
* X ON » XN : VECTOR 


origin; 


* 

* 

* 




loop 

ex it ui hen ._ IMP U 7 _.R =A5 X • - 

--3usy loop, waiting tor signal 
— corresponds to START_U? 

end loop; 

loop 


M.O..V E. C X ? D N.» X P.D.N _ L 0 C_..} ; . 

?UT_LINE( "C") J 

MOVE < XPON'F , X ? 2 N P_LGC 5 : 

H C VIC X N? , .. X tj P3.LGC_); .... 

XN := X ; i ? 3 - 1.5*H*(XP0N - 3.0*XPQNP); 
X 0 N ;= OcRIVATIVKXN); 

TR.ANS F.E.R.C X ON , 

Q _ t 5 s l< . 

X2NP2 LCC ); 


3 > 


i • 
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I 


This Ada progra-i consists of several compilation units and compiles 


* 


TRANSr E C X M , 

. . .. 3_.task.t_ 

X N ? 2 _ L C C ): 
TRANSFSRCXN, 

A. _ t.a_=.i< 

X N P 2 _ L D C ); 

loop 

. exit._VJ'na.n. IMPU7_F1EA2Y 5 
- - 2 u s y loop » wait! r, c tor 
— corresponds to S=5U«c 

end loop.5 

end loop; 

end Cl 


soon: 




t a s !< body 2 is 

XDN.P 2 , . XM P.3 . V r C 7.C.R. ? 

XNP ; VECTOR := ORIGIfi; 




.begin ........ . 

loop 

exit when I'.'E 'J7 _n v A .2 Y ; 

. . - - 3 u s y. . .1 o c p > . u-ai.ting for 
--corresponds to ST4RT_U? 
end loco; 

-.loop 

.*•’ G V E ( X D f! ? 2 , X 2 N ? 2 _ L C C ) ; 

~ U T _ L "l N‘ : C ”2") : 

M3VSCX.NP3, X N P 3_luC ); 

X N F : = XM°3 + Z . 0 * h * 'A 2 ill 
T R Afi SF 5 R ( XKP , 

2_tc.sk, 

X = 3 _ L C C ) : 
t ;■ a :: s c = r c x t; = , 

C_ta.sk, 

x r . 1 - e _ L 0 C ) : 

loop 


. g n - 1 


. exit when.. iNr'J.T.R r ADY 5 

- - E u s y loop, waiting to: 
--ccrrespcnos to -2 E SOME 


s i o n a i 
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ORIGINAL PAGE IS 

OF POOR QUALITY 


r> 


> 


This Ada program consists of several compilation units and compiles 


# end 

end 

end Di 

> 


task body I CP is 

# XPNX, 

. . XPNX.2 V.Z.C.T.O.R 

Si : INTEGER : = .1 : 

• I I_N .JLL.Q ..o.S ? 

TV : array Cl. .500 

■'> XV : array Cl.. 500 

begin 

# loop 

.e.x.i_t.._uj tl.e 0 .... I.N.P U.T_ R.S A O.Y 5 

--Susy 1 o o p » waiting for sign a! 
0 --c or r a sponds to STAF:T_U? 

. e nd ..loop.; . 

— accept RESUME? 

0 tvci) ;= tin; 

T.RA.N S.£.E.R_.C..C..MT.E C ll 5.R . SIGNAL ; .. 

# 

t or. . I- _in...l ... N.„ loop . . . 

PUT.LIMSC "?") ; 

# --accept RESUME: 

. . M C V E C X.? ii X 2 t X ? N X 2 _ L 0 C ) 5 

M C V c C X ? M X t X ° -V X _ L 0 C 5.' 

0 loop 

s.xi.t...ui.h.an . INF UT_R S AD Y ! 

— Susy loop* aaitin j for si anal 

# --corresponds to RESUME 

_end. loop.; . _ 

XVCS1 5 := F I R S T C X D N X ) : 

0 X'VCSl + 15 := r I R s T C X ? *>' X 2 ) ; 

-_i.f I. _>... 1 _.then_ .. 

TVCS15 := TVCS1 - 15 + H : 

0 end it ; 


of FLOAT; 

of float; 


loop; 

loop : 


t 
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ORIGINAL PASS IS 

OF POOR QUALITY 




With global! usa global; 


With global; use glooal; 

with .vec.Lo.ns.5 _u.s.e.._v..e.c.to.rs.; 

package EUS is 

INPUT _REAOY : boolean := true? 

typ9_3.U.S_A_0DR_.is __CX?DN_LQC , X?.NX2_L.DC , XO.MP 2_L0.C XNP2.LQC, 

y on»,!p_LCC , XPNX.LOC, XNP3.L0C)? 


BUS V : ARRAY (3U3_ADDR) of VECTOR; 

pr.o.ce.ciur.e....K.Q.VE_ C. ..T.Q.. ? .out. VECTOR.; 

"ROM : 0 U $ _ A DOR) t 

p r oce d.ur .■?. .. T ? A NS.rER.. C Value ; V - C T C R ; 

5 E N D _ T 0 : T A SK_*JA M E J 
ADDRESS : 3US ADO R ) J 


end 3U3 ; 

oritn _tex/t_i.o* .use._.text_ic- ; 
package body 3US is 

.. p.r.oc.edu r.e„ifi.CV.S ..C~TQ : out vectq.r; ... . 

R 0 v ‘ : DUS.ADOR) is 

..begin 

put_lina(":,;ov3") : 

PUT _L I N E ( " L " D ; 

— T.G.. 7= -EUSVCFP.OM) ; 

?ut_l:me( "l") ; 

end move; 


procedure TRAM'S 


9 


SEND TC 


: vector; 

: task name: 


ADDRESS : 3 US ADDS) i< 


be jin 


put _1 in e(" transfer" 5 : 


k.-22 


* 


With global; use global; 

e 

% D'JSVC ADDRESS) ; = VALUE; 

null.; 

end; 

• 

i end BUS; ... .. . 

i 

• 

% 

* 

I 

I 

I 

» 

♦ 

» 

— * • i r-**. - 
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